Dialog applications provide a voice user interface that allows an application user to interact with other computer applications to perform various tasks. For example, a voice user interface may allow a telephone caller to check charges on their credit card or manage travel plans. The dialog application responds to caller inputs and response by providing various dialog prompts that advance the caller through a specific task.
FIG. 1 A-C illustrates various ways to implement a portion of a simple dialog process to determine a desired travel destination of a caller. Each of the three sample calls shown has an initial collection process followed by a confirmation process. Each of three different dialogs starts with the same initial system prompt, an inquiry to the caller: “Where are you flying to?” In FIG. 1A, the User replies, “Boston,” ending the collection process and entering the confirmation process in which the next system prompt is for confirmation of the previous input: “Ok. Austin. Please say yes or no.” In the dialog shown in FIG. 1A, the caller response, “No.” sends the process back to the beginning of the collection process where the first system prompt is repeated. The process depicted in FIG. 1B is slightly different in that the user responds to the confirmation prompt with: “No, Boston.” That response returns the dialog application back to the beginning of the confirmation process where the confirmation prompt is repeated (hopefully with Boston instead of Austin). FIG. 1C depicts another variant dialog in which the caller response to the collection prompt is different: “I'd like to fly to Boston tomorrow.” The resulting confirmation prompt is more complex, seeking to confirm both destination and time.
Designers of voice user interfaces tend to model user interactions with the dialog system they are creating by sketching out sample calls. Sample calls are scripts that outline how a conversation might proceed between a caller and the automated dialog system. The interface designer uses these sketches to provide examples of how a caller might accomplish a particular task and to layout the interaction style that is to be adopted. Each sample call corresponds to a path through the structure of an application.
Designing with sample calls allows modeling of the sample interaction paths through the dialog application without requiring that the complete system structure be fully defined. Additionally, the designer can better focus on creating a user dialog experience that effectively and efficiently completes the task rather than being stifled by details that are overly technical or architectural (but which need attention at some later phase in designing the system).
Commonly, voice interface designers write sample call sketches on paper or in text documents that are then used to communicate their design intentions with the major application stakeholders. This methodology has provided benefits to the designers and stakeholders for understanding how the dialog will flow, but these benefits are short-lived. The information captured in the sample calls often becomes stale, and the initial sample calls remain very much “preliminary” sketches that are not easily integrated or accessible for the next phases of the system design such as creating the application structure (“call flow”) and specifying details around each step of the user dialog interaction.
Shortly after the sample calls are completed and communicated to the application stakeholders, the information presented in them (e.g., prompts and grammars) becomes out of date and no longer representative of the current system design, and thus not useful. As designers move to subsequent phases of the application design, they end up recreating a new version of the call information and are forced to stay in the mode of the next phase of design.